An important consequence of the queuing behavior of IP networks is that packets must spend time waiting in the queues of networking devices. This waiting time, often called the “queuing time” or “queuing delay”, can degrade the resulting performance of higher layer protocols and applications that utilize the network path through such devices because extra delays are injected into the conversation of two or more communicating end points. Moreover, when the packet rate on a given output port exceeds the port's capacity for a sustained period of time—a phenomenon called network “congestion”—the queue will continue to grow and at some point the networking device will have no choice but to discard certain packets altogether.
There is a delicate tradeoff in how such decisions are made because if the queue is allowed to grow very large, then the queuing delays become large and adversely impact performance. Conversely, if the queue is limited to be very small, then the networking device is not able to absorb bursts of traffic and may drop packets too aggressively likewise causing an adverse impact on performance. Sometimes packets are marked to indicate congestion (using explicit congestion notification, or ECN) to signal to the end points to lower their transmission rates, rather than dropping the packets outright.
When packets are dropped because of congestion, the transport protocol running in the end system affected by such dropped packets typically reacts by adjusting its sending rate downward. For example, TCP follows the well-known additive-increase, multiplicative-decrease (AIMD) congestion control scheme. Roughly speaking, TCP increases its transmission window additively on each round-trip in which no packets are dropped, and decreases its window multiplicatively when packet loss is detected.
Because the window size limits transmission, TCP's throughput in the best case is limited by the window size W divided by the roundtrip time RTT or (W/RTT). However, TCP's throughput is also limited by the way in which the window opens and closes in the presence of packet loss. In an AIMD scheme, the throughput is proportional to 1/sqrt(p) where p is the rate of packet loss. Accordingly, the overall throughput of TCP is proportional to 1/(RTT*sqrt(p)). This means that increases in network latency and increases in packet loss rates each have a negative effect on TCP throughput, but also that the two problems in combination aggravate each other.
Even with these problems TCP is widely used because TCP achieves a reliable ordered byte-stream service implemented by the end hosts over an underlying IP network that actually supports only best-effort (unreliable) delivery of datagrams with possible reordering en route. With its congestion control mechanisms, TCP is also “network friendly” to other TCP and non-TCP traffic that is sharing the same network link. A common test for a proposed transport protocol is whether it is similarly “TCP friendly” or “network friendly.” However, there are also circumstances in which a network link is completely controlled by a given party, and the controlling party is willing to sacrifice network-friendly behavior if they can get better performance for their traffic across the link.
There are also environments in which TCP's behavior is undesirable. In wireless networks, ordinary TCP cannot distinguish between packet loss due to congestion and packet loss due to corruption. When the packet losses are caused by noise corrupting packets, it is undesirable for the sender to back off. A variety of systems have been proposed and/or implemented to improve TCP behavior in such circumstances. One worth noting (by Balakrishnan et al.) involves the introduction of a snoop agent that both caches TCP packets (to avoid the need to resend them) and suppresses some TCP responses (to avoid shrinking the window inappropriately).
Broadly speaking, the congestion-control mechanisms of TCP are powerful but far from perfect, and there are circumstances in which it is important to work in a better way than the ordinary behavior of TCP. There is also a tension between the desire to have systems that are adaptive, scalable, and built on end-to-end principles on the one hand; and to have systems that deliver predictable or guaranteed levels of service to some forms of traffic on the other hand.
It is therefore desirable to improve upon the prior art in both networking quality of service as well as transport protocol design. It is also desirable to improve the performance of TCP and similar protocols over specific links or network paths that are subject to high latency, a high bandwidth-delay product, high packet loss, and/or bit errors.